[Previous] [Next] [Index] [Thread]

RE: N$ SSL vs M$ PCT

> From: maracchini_dave  <a-davem@ac.tandem.com>
> Subject: RE: N$ SSL vs M$ PCT
> Date: Thursday, October 05, 1995 10:09AM
>
>
> Virtually ALL protocols proposed for use in protecting commerce on the
> Internet (e.g., S-HTTP) have holes have holes large enough to drive a truck
> through PRECISLY because they do not limit key use to a specific purpose.
> A key should NEVER be used for more than one purpose in order to minimize
> the risk of key/data substitution attacks. This principal is one of the
> necessary conditions for securing transactions and hold true for both
> symetric (e.g., DES) and asymetric (e.g., RSA) crypto systems.
>
> The dominant payment networks (i.e., Bank ATM, CIRRUS, INTERLINK, etc.)
> have long ago recognized this fact - the key used to transmitt other keys
> is different from the key used to encrypt PINs, is different from the key
> used to authenticate the authorization request, is different from the key
> used to authenticate the authorization response, etc.
>
> Regards, Dave
>


Dave,

You're right that many protocol specifications do not explicitly
state that the cryptographic keys that they specify should not be
used in other ways.  It is clear to cryptographers that if one were
to use one's cryptographic keys in a different cryptographic protocol
-- or publish them (using the trivial, publish-everything protocol,
e.g., use cryptographic keys as passwords sent in the clear) -- the
security of the original protocol could well be compromised.  Even if
the other protocol is a carefully designed cryptographic protocol,
the simultaneous use of two protocols can lead to a compromise of one
or both of the protocols.

When cryptographers design cryptographic protocols, admonition
against multiply using cryptographic keys are taken for granted --
these are motherhood and apple-pie.  And note that -sometimes- the
same cryptographic key may be used in several protocols safely:
RSA-based key exchange, for example, is often a building block of
many protocols, and using a single RSA key-pair in multiple protocols
to receive a symmetric key would be okay in most cases -- it's just
that we have to think carefully before reusing keys.

You're right that there is an important cryptographic design issue
here: in both SSL and PCT, the client authentication key is assumed
to be a signature key, and you might wonder if the same client key
(and associated certificate) might be used to sign other documents.
For PCT, if you examine the client authentication response field
CMK_RESPONSE_DATA is a simple digital signature of the verify-prelude
field CMK_VERIFY_PRELUDE.  Since verify-prelude is

    hash(CLIENT_MAC_KEY, hash("cvp", CLIENT_HELLO, SERVER_HELLO)

and both CLIENT_MAC_KEY and CLIENT_HELLO is derived from or contains
cryptographically secure pseudo-random values chosen by the client,
the server (or an attacker) will not have an opportunity to control
the verify-prelude value (unless the hash function fails to have any
reasonable cryptographic properties at all).

This still doesn't completely answer the question of multiple use.
If the client signature key is used for "normal" hash-and-sign
documents where the user choses the document, there shouldn't be a
problem (due to the
nobody-else-can-control-the-verify-prelude-hash-result property).
However, if the signature is used in another protocol where the
client may be asked to sign the hash of a document provided by a peer
(potential attacker), we'd have to be more careful -- the attacker
could certainly be attempting to masquerade as the legitimate client
in a run of PCT, and use this other protocol and provide the
concatenation

    CLIENT_MAC_KEY, hash("cvp", CLIENT_HELLO, SERVER_HELLO)

from the attacker's masquerading session as the document to be
signed in this other protocol.

So, you're right, but the point that you're making is well known.
All protocols, including PCT, cannot stand if their cryptographic
keys are carelessly reused in other protocols.  However, I don't
think that you should be pointing your finger at all these protocols
and declaring that there is a fundamental failure; perhaps the
problem is really more of a lack of communication between
cryptographic protocol designers and non-cryptographers such as
yourself.  Crypto people assume that the implementers won't do the
wrong thing (e.g., use good, cryptographically secure pseudo-random
number generators that are seeded properly with a seed of sufficient
length whenever appropriate, not dump core when given unexpected
inputs, etc) when their protocols are cast into code; sometimes
that's an invalid assumption.

-bsy
Follow-Ups: